1. Field of the Invention
The present invention relates to a method and terminal device for handling a suspended network state, for example in an Internet Protocol Multimedia Subsystem (IMS).
2. Description of the Related Art
In order to achieve access independence and to maintain a smooth interoperation with wired terminals across the internet, the IMS as specified e.g. in the 3GPP specification TS 23.228 has been developed to be conformant to IETF (Internet Engineering Task Force) “Internet Standards”. The IP multimedia core network (IM CN) subsystem enables network operators of mobile or cellular networks to offer their subscribers multimedia services based on and built upon Internet applications, services and protocols. The intention is to develop such services by mobile network operators and other 3rd party suppliers including those in the Internet space using the mechanisms provided by the Internet and the IM CN subsystem. The IMS thus enables conversions of, and access to, voice, video, messaging, data and web-based technologies for wireless users, and combines the growth of the Internet with the growth in mobile communications.
FIG. 1 shows an architecture of an IMS network according to the above 3GPP (3rd Generation Partnership Project) specification. The architecture is based on the principle that the service control for home subscribed services for a roaming subscriber is in the home network HN, e.g. a Serving Call State Control Function (S-CSCF) is located in the home network HN. In FIG. 1, an S-CSCF 10 is shown, which controls a terminal device or user equipment (UE) 40. In general, the S-CSCF 10 performs session control service for the served UE 40. It maintains a session state as needed by the network operator for support of the services which may be provided by an application server (AS) 60 which may be located as well in the home network HN or a visited network VN.
Within an operator's network, different S-CSCFs may have different functionalities. The functions performed by the S-CSCF 10 during a respective session may be e.g. registration, session flow management, charging and resource utilization management. When a subscriber roams to the visited network VN, the visited network VN supports a Proxy-CSCF (P-CSCF) 30 which enables the session control to be passed to the respective S-CSCF 10 located at the home network HN and providing the service control. Furthermore, an Interrogating-CSCF (I-CSCF) 50 is provided in the home network HN as a contact point within the operator's network for all connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area. There may be multiple I-CSCFs within an operator's network. The functions performed by the I-CSCF 50 include assigning the S-CSCF 10 or any other S-CSCF to a user performing a registration procedure, routing a request received from another network towards the S-CSCF 10, obtaining the address of the S-CSCF 10 from a subscriber database, e.g. a Home Subscriber Server (HSS) 20 as shown in FIG. 1, and/or forwarding requests or responses to the S-CSCF 10 determined based on the address obtained from the HSS 20.
The P-CSCF 30 is the first contact point within the IMS. Its address may be discovered by the UE 40 following a PDP (Packet Data Protocol) context activation. The P-CSCF 30 behaves like a proxy, i.e. it accepts requests and services them internally or forwards them on, possibly after translation. The P-CSCF 30 may also behave as a User Agent, i.e. in abnormal conditions it may terminate and independently generate transactions. The functions performed by the P-CSCF 30 are forwarding register requests received from the UE 40 to an I-CSCF, e.g. the I-CSCF 50, determined using the home domain name as provided by the UE 40, and forwarding requests or responses to the UE 40.
Further details regarding the functions of the different CSCF elements shown in FIG. 1 can be gathered from the above mentioned 3GPP-specification.
The IETF has been specifying a Session Initiation Protocol (SIP) event package for registrations, as defined in “draft-ietf-sipping-reg-event”. Through its REGISTER method, SIP allows a user agent, which is an interface (e.g. browser) between the user and the network application, to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. The event package defines a mechanism by which those user agents can request and obtain such notifications.
The SIP REGISTER method provides a way for a user agent to manipulate registrations. Contacts can be added or removed, and the current set of contacts can be queried. Registrations can also change as a result of administrator policy. For example, if a user is suspected of fraud, his registration can be deleted so that they cannot receive any requests. Registrations also expire after some time if not refreshed. Thus, registrations represent a dynamic piece of state maintained by the network. The SIP Events Framework defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events, e.g. registration states.
The SUBSCRIBE message for the registration package may contain a body for filtering the subscription. It may be sent with or without the body. The default registration policy is that notifications are triggered from a SUBSCRIBE message and are generated every time there is a change in the state of any of the registered contacts for the resource being subscribed to. Those notifications only contain information on the contacts whose state has changed. The notifications are forwarded using the NOTIFY message comprising in its body a registration information document which describes some or all of the contacts associated with a particular address-of-record.
Every user has one or more private user identities. The private identity is assigned by the home network operator, and used, for example, for registration, authorisation, administration, and accounting purposes. The private identity takes the form of a Network Access Identifier (NAI) as defined in specification RFC 2486. It is possible for a representation of the IMSI (International Mobile Subscriber Identity) to be contained within the NAI for the private identity. Additionally, every user has one or more public user identities. The public user identity is used by any user for requesting communications to other users. For example, this might be included on a business card.
In the 3GPP IMS Release 5 specifications TS 24.229, 24.228 and 23.218, the SIP registration state event package is used to inform about the user's registration state to the subscribers of the event package. Furthermore, the above specifications require that the UE 40 maintains the registration with the IMS network. It is further specified in the 3GPP specification TS 24.229 that whenever the IMS network sees the need to deregister at least one of the user's registered identities or the user from the network, the S-CSCF 10 generates a NOTIFY request towards the UE 40. If the NOTIFY request includes one or more <registration> elements with a state attribute set to “terminated” and an event attribute set to “rejected” or “deactivated”, the UE 40 must remove all registration details related to these public user identities. If the event attribute is “deactivated”, the UE 40 must start the initial registration procedure. If the event is “rejected”, the UE 40 must release all dialogs that use those public identities.
In case the UE 40 receives a NOTIFY request in which all <registration> elements have their state attribute set to “terminated” and a Subscription-State header contains a value “terminated”, the UE 40 must delete security associations towards the P-CSCF 30 after NOTIFY server transaction terminates, i.e. the network has deregistered the user from the network.
However, if a network connection (e.g. PDP context) towards the UE 40 is suspended for a while, for instance due to a circuit switched call in GERAN (GSM/EDGE radio access network) without DTM (Dual Transfer Mode) support in the UE 40, the NOTIFY request may not reach the UE 40 and it will remain in an inconsistent state after the network connection is resumed again. This inconsistent state means that the UE 40 will have available only invalid information about the registration state of the user or of some of the user's public identities. Consequently, in this case, the above requirements set out by the 3GPP specification TS 24.229 are violated. The end user and the UE 40 assume a valid registration to the network, while this is no longer the case. In this case, initiation or reception of services relating to the deregistered user identity/identities is no longer possible, but the end user cannot understand a reason for this, since he still assumes a valid registration.